1. Field of the Invention
The present invention relates generally to computer software for testing programs in a large computing environment. More particularly, the invention relates to techniques for automatically generating a test environment that reflects changes or additions made to a production environment.
2. Discussion of Related Art
In complex batch-processing computing environments, typically performed on mainframe computers in large enterprises, testing and maintenance of programs that run in the xe2x80x9creal-worldxe2x80x9d business environment, known as production, have to be performed frequently and reliably. For example, if one program is changed, each of the batch-processing jobs that call that program would likely have to be tested. Furthermore, each batch-processing job might have to be tested for many reasons including year 2000 compliance, user interface, and financial accuracy.
Errors or mishaps in production affecting actual business data can have serious technical ramifications which, more importantly, can lead to adverse business consequences. Not only do production programs and modules need to be tested often, but also because of the large and occasionally enormous processing load, management and maintenance of the testing environment is itself a significant task requiring much time and effort. Even with well-staffed testing and quality assurance teams at many organizations, the testing process is still error-prone, mainly because it is still manually intensive despite some degree of automation.
FIG. 1 is a block diagram comparing production and test environment components as is well known in the field of software testing in a batch processing environment. A production computer 100 has access to various production data storage areas containing various programs and data. The program and data of primary interest here are the production Job Control Language (JCL) programs, referred to as members, 102 and production data files 104. JCL members 102, also referred to as jobs, are programs that control the management of data files and the execution of programs, such as COBOL or DB2 programs, comprising the batch processing on the production computer. As is known in the art of computer programming, the JCL programming language, originally developed by the IBM Corporation, is used to control the flow of program execution in a batch processing environment, such as in IBM""s MVS operating system. Batch processing in the MVS environment typically runs on mainframe computers and involve hundreds or thousands of batch programs. JCL members and batch processing are tools and techniques well known in the computer field, specifically the field of mainframe computing.
Production data files 104 are data files that contain actual data used in production, these files may be flagged as production files by, for example, beginning with the letter xe2x80x9cPxe2x80x9d. These data files can include, for example, database files containing production data. The letter xe2x80x9cPxe2x80x9d is also used to distinguish JCL members and other production-side data as production items. Updates to production data must only reflect actual business transactions. Also associated with production computer 100 are data storage areas for production xe2x80x9cPROCsxe2x80x9d or procedures 106 and production xe2x80x9cPARMsxe2x80x9d 108. PROCs are essentially subroutines called by JCL members 102. PARMs are used by JCL members and production programs (i.e., the actual data processing programs whose execution is controlled by the JCL members) to set runtime parameters.
A test environment includes a test computer 110, typically another mainframe computer in the batch processing context. Test computer 110 also has various data storage areas that generally mirror data storage areas on the production side. One of the data storage areas contains test JCL members 112 and test data files 114. The files can include control and historical files, as well as input files. The test data and programs in these storage areas may be distinguished from production data and programs, e.g., by placing an indicator such as the letter xe2x80x9cTxe2x80x9d at the beginning of each data file and program name. Another data storage area holds test PARMs 116 used by test JCL members that are somewhat different from production PARMs 108. Because the test JCL members do not perform in exactly the same manner as the production JCL members, the test programs normally do not use production PARMs 108. However, test JCL members 112 can use production PROCs 106.
FIG. 2 is a flow diagram showing a process of manually creating a test environment from a production environment as is known in the art. At step 202 production JCL members 102 that are to be tested are copied from a controlled production library into a tester-controlled library (e.g., a tester""s private library) or test group-shared library. Also copied are the production PROCs needed to test the JCL members. At step 204 changes and overrides are made to the copies of the production JCL members to reference the desired test environment. This typically involves changing library concatenations to suit the particular test being performed (e.g., ensuring that they point to appropriate test modules). The overrides are generally made to PROC parameters so that they reference the desired test environment. This step is manually intensive since it involves examining each PROC that is called by the JCL, determining which PROC parameters can be overridden in the JCL and editing those values. This needs to be done for each test run. It is generally an error-prone and time consuming process.
At step 206 the tester must examine the test JCL to check the input and output data files used by the test JCL. Proprietary tools can be used to scan the test JCL and provide a report of referenced files (referenced files can be hidden in the programs and thus are not easily detectable by a human tester). The tester may need to scan the report to make sure the test JCL members point to the right data files. The tester must also check for any other errors in the test JCL which typically involves manually scanning the JCL members. This step is also manually intensive and requires significant effort and attentiveness on the part of the tester to catch errors.
At step 208 the tester determines whether any corrections or overrides are needed for the test JCL after examining the programs at step 206. If corrections or overrides are required, they are made at step 210. At this step the tester generally builds any missing files needed by the test JCL and makes any overrides to the data sets. If no corrections or overrides are needed, the tester places the test JCL in a user-controlled library for execution on the test computer. The test JCL is now in condition to be used for the actual testing of the production JCL copied at step 202. Up until this point, all the steps were needed simply to prepare the JCL members for actual testing.
In addition, there is presently no completely automatic process for keeping files and programs up to date (i.e., consistent with current programs and files that are being tested). This still has to be done manually by the tester. Once in the user-controlled library, testing the JCL will require access to a JCL or job scheduler which contains the flow or order in which the JCL members (of which there can be hundreds) will execute. Presently, there are no tools that can provide the tester with a visual representation of the job flow for the particular test being performed.
One attempt to automate the process of preparing test JCL involves using xe2x80x9cskeletonxe2x80x9d JCL members. These programs contain symbolics in place of actual variable names which are substituted with variables or other data during execution. The symbolics are programmatically converted to variables. Typically there are many skeletons of a JCL member or program where each skeleton can be used in a different test thereby enabling rapid population of test JCL members and allowing many tests using the same JCL member to run at the same time. However, skeleton programs still have to be maintained in so far that changes in production JCL members still have to be reflected in the skeleton program.
Therefore, it would be desirable to automate the process of generating a test environment for testing JCL in which all necessary checks and adjustments required to ensure that the test JCL members run properly are done with reduced human intervention. In addition, it would be desirable to have JCL generated in such a way that similar test environments are logically subdivided. Furthermore, it would be desirable to generate and schematically display job flow diagrams so that testers can view a particular job flow for the test being performed.
To achieve the foregoing, methods, apparatus, and computer readable media are disclosed which provide automated generation of a JCL test scenario in a batch computing environment. In one aspect of the invention, a method of automatically generating a test environment for testing control programs in a batch computing environment is disclosed. A control program list containing the names of control programs that have been added or modified and need to be tested is created. Custom characteristics of the test scenario or environment are specified. It is determined whether any of the procedures called by the control programs needs to be modified. The custom characteristics are incorporated into the control programs and modifications are incorporated into the procedures called by the control programs. Advantageously, a test scenario in which control programs in a batch computing environment can be tested is generated with greatly reduced manual or human intervention.
In one embodiment, a set of external characteristics is incorporated into the control programs. In another embodiment, errors, if any, relating to data set names in the control programs and in the one or more procedures are determined. In yet another embodiment, modifications to the one or more procedures are incorporated by reading the control programs, identifying the procedures invoked by the control programs and symbolics in those procedures, and overriding the symbolics in the procedures. In yet another embodiment, symbolics in the procedures are matched with symbolics specified by a user. In yet another embodiment, the control programs are job control language (JCL) programs and the batch computing environment operates under the Multiple Virtual Storage (MVS) operating system. In yet another embodiment, a variable name is retrieved from the control programs and it is determined whether the variable name is in a user override file. If so, the variable name is replaced with an override name.
In another aspect of the invention, an automated test job control language (JCL) generation tool for creating a JCL test scenario is described. Input to the generation tool includes JCL code corresponding to the JCL members being tested, a list of procedure or PROC libraries and a list of parameter or PARM libraries used by the JCL members, external specifications, reference control files, and overrides. A JCL test scenario is created that includes test JCL libraries, test versions of the reference control files, and test parameter files.
In one embodiment the reference control files are referenced by the JCL members. In another embodiment the referenced control files contain updateable control and history files. In yet another embodiment, the external specifications contain date values, high-level qualifiers, and library concatenations to be used in the JCL members and procedures. In yet another embodiment, the overrides include procedure symbolics or variable names and data set names.